User-Centred Requirements Handbook |
In order to help users visualise the possible system and to clarify user requirements, a rapid prototype or simulation of the system should be developed. This will demonstrate system concepts or specific features.
The aim of this section is to draw out from the Design Concept the main features of the system and the functions it should provide for development into an interactive prototype.
Process
The user interface can be prototyped in different ways, for example,
• as a prototype or simulation of the system concepts produced in software.
• as a simulation of the system, the interface being controlled by a person, acting as the system and responding to user input. This is known as a 'Wizard of Oz' simulation.
• as a video simulation showing the concept behind the system.
There are a number of key issues, however which need to be considered (Maguire, 1996):
• Keep within design limitations
It is important to create a prototype which stays within the likely limits of the design context. For example, the prototype should be developed to run on the hardware that most users will have and to exhibit similar response times. This will avoid raising user expectations which will lead to disappointment when the real system is implemented.
• Take account of likely data volume and structure
A prototype system may appear to present a simple interface based on the example data that is incorporated into it. However in the real situation, pick lists may be longer, data records may contain more text, and there may be many more of them, which may affect the usability of the system in use. Similarly, a process control system prototype may appear manageable since the range of displayed messages or warnings is limited. However unforeseen problems may occur producing messages from the full range when the complete system is running.
• Be aware of user representatives becoming too technically aware
It is recommended that users are closely involved in the development of system prototypes and their inputs will help match the system to user needs. However as the process of development continues, and users learn more about the technology behind the system, and the concepts and jargon of software design, there is a tendency for them to lose sight of the problems that non-technical users may face. Thus users not involved in system development should be brought in to provide feedback on the developing prototype.
• Over Reliance on Prototyping
It is possible that the design team may place too much reliance upon prototyping activities. By assuming that the prototype will capture the essence of the whole system, it can lead to poor specification. If the prototype is seen as the specification itself, then designers may fail to consider the more hidden aspects of the system with the result that they will be implemented poorly. It is important then that internal aspects such as data structures and communications links are considered in terms of their possible effect on user requirements.
Please refer to Appendix 1 which offers general guidelines on the design of user interfaces.